Translation modeling methods and systems for simulating sensor measurements

ABSTRACT

Disclosed are methods and corresponding systems and devices for providing an estimation model for use with one or more instances of a particular sensor. In some aspects, an estimation model usable for estimating a value of a physiological condition is determined based at least in part on simulated measurements. The simulated measurements are generated for a first sensor, through applying a translation model to convert historical measurements associated with a second sensor into measurements that would have been produced by the first sensor. The second sensor has a different design or configuration than the first sensor. The historical measurements represent changes in the physiological condition as observed by different instances of the second sensor. The estimation model can be made available to one or more electronic devices, including at least one device configured to apply the estimation model to a measurement from a corresponding instance of the first sensor.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/848,687, filed Apr. 14, 2020, entitled “TRANSLATION MODELING METHODSAND SYSTEMS FOR SIMULATING SENSOR MEASUREMENTS,” which claims thebenefit of U.S. Provisional Patent Application No. 62/945,800, filedDec. 9, 2019, entitled “METHOD AND SYSTEMS FOR SIMULATING SENSORMEASUREMENT DATA,” the contents of which are incorporated by referenceherein in their entirety.

TECHNICAL FIELD

Embodiments of the subject matter described herein relate generally tomedical devices, and more particularly, embodiments of the subjectmatter relate to calibrating sensing devices for use with medicaldevices, such as fluid infusion devices.

BACKGROUND

Infusion pump devices and systems are relatively well known in themedical arts, for use in delivering or dispensing an agent, such asinsulin or another prescribed medication, to a patient. Control schemeshave been developed to allow insulin infusion pumps to monitor andregulate a patient's blood glucose level in a substantially continuousand autonomous manner. Rather than continuously sampling and monitoringa user's blood glucose level, which may compromise battery life,intermittently sensed glucose data samples are often utilized forpurposes of continuous glucose monitoring (CGM) or determining operatingcommands for the infusion pump.

Many continuous glucose monitoring (CGM) sensors measure the glucose inthe interstitial fluid (ISF). Typically, to achieve the desired level ofaccuracy and reliability and reduce the impact of noise and otherspurious signals, the sensor data is calibrated using a known good bloodglucose value, often obtained via a so-called “fingerstick measurement”using blood glucose meters that measures the blood glucose in thecapillaries. However, performing such calibration measurements increasesthe patient burden and perceived complexity, and can be inconvenient,uncomfortable, or otherwise disfavored by patients. Moreover, ISFglucose measurements lag behind the blood glucose measurements based onthe time it takes glucose to diffuse from the capillary to theinterstitial space where it is measured by the CGM sensor, whichrequires signal processing (e.g., filtering) or other techniques tocompensate for physiological lag. Additionally, various factors can leadto transient changes in the sensor output, which may influence theaccuracy of the calibration. Degradation of sensor performance over timeor manufacturing variations may further compound these problems.

To decrease the patient burden associated with obtaining referencemeasurements and improve the user experience, machine learning orartificial intelligence techniques have been utilized to develop modelsfor generating calibrated measurements. However, to avoid compromisingaccuracy or reliability, these approaches often require relatively largedata sets to achieve the desired model performance. Obtaining large datasets often entails increased time and costs associated with datacollection, which is a significant clinical burden when utilizing suchmodeling techniques in newly developed sensing devices that is achallenge to condensed development cycles or relatively limited clinicaltrials (e.g., a limited number of patients and/or a limited trialduration). Accordingly, it is desirable to provide support formodel-based calibration in situations where limited data is available.

BRIEF SUMMARY

The subject matter of this disclosure generally relates to determiningvarious types of predictive models and using the models in connectionwith monitoring a physiological condition. Such models may includeglucose estimation models or other predictive models that operate onsensor output.

In one aspect, the present disclosure provides for a computer systemincluding one or more processors and memory storing instructionsexecutable by the one or more processors. When executed, theinstructions cause the computer system to perform operations includinggenerating simulated measurements for a first sensor based on historicalmeasurements associated with a second sensor. The second sensor has adifferent design or configuration than the first sensor. The historicalmeasurements represent changes in a physiological condition as observedby different instances of the second sensor. Generating the simulatedmeasurements involves applying a translation model to convert thehistorical measurements into measurements that would have been producedby the first sensor. The operations further include determining anestimation model using the simulated measurements. The estimation modelis configured to estimate a value of the physiological condition givenan actual measurement from the first sensor. The operations furtherinclude providing one or more electronic devices with access to theestimation model. The one or more electronic devices include at leastone device configured to apply the estimation model to a measurementfrom a corresponding instance of the first sensor. For example, theestimation model can be applied to convert the measurement from thecorresponding instance of the first sensor into an estimated value ofthe physiological condition.

In some aspects, the operations of the computer system determining theestimation model include determining the translation model based atleast in part on relationships between first measurements associatedwith the first sensor and second measurements associated with the secondsensor. The second measurements are separate from the historicalmeasurements. For instance, each of the first measurements can becaptured contemporaneously with a corresponding one of the secondmeasurements.

In some aspects, the estimation model is determined through analyzingthe simulated measurements together with reference values for thephysiological condition. For example, the first sensor and the secondsensor can be interstitial glucose sensors, and the reference values caninclude blood glucose measurements. The determination of the estimationmodel can involve determining relationships between the simulatedmeasurements and the reference values, where the reference valuesinclude a corresponding reference measurement for each of the historicalmeasurements. Additionally, the determination of the estimation modelcan involve analyzing actual measurements from different instances ofthe first sensor together with corresponding reference values. Theactual measurements from different instances of the first sensor caninclude measurements that were used to determine the translation model.

In another aspect, a method of providing an estimation model for usewith one or more instances of a first sensor involves generatingsimulated measurements for the first sensor based on historicalmeasurements associated with a second sensor. The method can beimplemented using the computer system described above. As discussedabove, the second sensor has a different design or configuration thanthe first sensor, and the historical measurements represent changes in aphysiological condition as observed by different instances of the secondsensor. Further, generating the simulated measurements includes applyinga translation model to convert the historical measurements intomeasurements that would have been produced by the first sensor. Themethod further involves determining the estimation model using thesimulated measurements. The estimation model is configured to estimate avalue of the physiological condition given an actual measurement fromthe first sensor. The method further involves providing, by the computersystem, one or more electronic devices with access to the estimationmodel. The one or more electronic devices include at least one deviceconfigured to apply the estimation model to a measurement from acorresponding instance of the first sensor.

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the detaileddescription. This summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

BRIEF DESCRIPTION OF DRAWINGS

A more complete understanding of the subject matter may be derived byreferring to the detailed description and claims when considered inconjunction with the following figures, wherein like reference numbersrefer to similar elements throughout the figures, which may beillustrated for simplicity and clarity and are not necessarily drawn toscale.

FIG. 1 depicts an exemplary embodiment of data management system;

FIG. 2 is a block diagram of an exemplary embodiment of a sensingarrangement suitable for use in the data management system of FIG. 1 ;

FIG. 3 is a flow diagram of an exemplary sensor translation processsuitable for use with the data management system of FIG. 1 in one ormore exemplary embodiments;

FIG. 4 is a graph depicting relationships between observed sensormeasurement data and simulated sensor measurement data in connectionwith an exemplary embodiment of the sensor translation process of FIG. 3;

FIG. 5 is a flow diagram of an exemplary real-time translation processsuitable for use with the data management system of FIG. 1 in one ormore exemplary embodiments;

FIG. 6 is a flow diagram of an exemplary generative modeling processsuitable for use with the data management system of FIG. 1 in one ormore exemplary embodiments; and

FIG. 7 depicts an exemplary embodiment of patient monitoring systemsuitable for use with one or more of the sensor translation process ofFIG. 3 , the real-time translation process of FIG. 5 , and thegenerative modeling process of FIG. 6 in one or more exemplaryembodiments.

DETAILED DESCRIPTION

The following detailed description is merely illustrative in nature andis not intended to limit the embodiments of the subject matter or theapplication and uses of such embodiments. As used herein, the word“exemplary” means “serving as an example, instance, or illustration.”Any implementation described herein as exemplary is not necessarily tobe construed as preferred or advantageous over other implementations.Furthermore, there is no intention to be bound by any expressed orimplied theory presented in the preceding technical field, background,brief summary or the following detailed description.

Exemplary embodiments of the subject matter described herein generallyrelate to calibrating sensing elements and related sensing arrangementsand devices that provide an output that is indicative of and/orinfluenced by one or more characteristics or conditions that are sensed,measured, detected, or otherwise quantified by the sensing element.While the subject matter described herein is not necessarily limited toany particular type of sensing application, exemplary embodiments aredescribed herein primarily in the context of a sensing element thatgenerates or otherwise provides electrical signals indicative of and/orinfluenced by a physiological condition in a body of a human user orpatient, such as, for example, interstitial glucose sensing elementsthat provide electrochemical signals indicative of and/or influenced bya glucose level in an interstitial fluid compartment.

As described in greater detail below, observed measurement data obtainedusing different instances of a sensing arrangement or sensing element isutilized to characterize the electrochemical behavior of the particularsensing arrangement or sensing element and generate a correspondingmodel of the electrochemical response by the particular sensingarrangement or sensing element. The electrochemical response model isthen utilized to generate simulated measurement data for differentrepresentative instances of the particular sensing arrangement orsensing element. The simulated measurement data is utilized, eitherindividually or in combination with the observed measurement data, togenerate a corresponding model for converting the electrical signalsoutput by respective instances of the sensing arrangement or sensingelement into an estimated calibrated measurement value. In this regard,by increasing the size of the data set being analyzed and modeled byincluding the simulated measurement data, the accuracy or otherperformance characteristics of the resultant model is improved. Asdescribed in greater detail below, in exemplary embodiments, a glucoseestimation model for mapping one or more electrical signals output by aninterstitial glucose sensing element into an estimated calibratedinterstitial glucose measurement value is developed, derived, orotherwise determined using simulated measurement data, thereby improvingthe accuracy, reliability and/or other performance characteristics ofthe glucose estimation model to facilitate obtaining effectivelycalibrated measurement values for the glucose level of a patient in amanner that reduces reliance on so-called “fingerstick measurement” orother reference measurements.

It should be noted that the subject matter described herein is notnecessarily limited to electrochemical signals, and in practice, couldbe implemented in an equivalent manner in the context of other types ofsensors and other multi-dimensional and/or time-dependent signals (e.g.,optical signals, electrical signals, or the like). Additionally, forpurposes of explanation, exemplary embodiments of the subject matter aredescribed herein as being implemented in conjunction with medicaldevices, such as portable electronic medical devices. Although manydifferent applications are possible, the following description may focuson glucose sensing devices, continuous glucose monitoring (CGM) devices,or the like. That said, the subject matter may be implemented in anequivalent manner in the context of other medical devices, such as afluid infusion device (or infusion pump) as part of an infusion systemdeployment, injection pens (e.g., smart injection pens), and the like.For the sake of brevity, conventional techniques related to glucosesensing, glucose monitoring, infusion system operation, insulin pumpand/or infusion set operation, and other functional aspects of thesystems (and the individual operating components of the systems) may notbe described in detail here. It should be noted that the subject matterdescribed herein can be utilized more generally in the context ofoverall diabetes management or other physiological conditionsindependent of or without the use of an infusion device or other medicaldevice (e.g., when oral medication is utilized), and the subject matterdescribed herein is not limited to any particular type of medication. Inthis regard, the subject matter is not limited to medical applicationsand could be implemented in any device or application that includes orincorporates a sensing element.

FIG. 1 depicts an exemplary embodiment of a data management system 100suitable for implementing the subject matter described herein. The datamanagement system 100 includes, without limitation, a computing device102 coupled to a database 104, with the computing device 102 also beingcommunicatively coupled to any number of additional electronic devices106, 108 over a communications network 110, such as, for example, theInternet, a cellular network, a wide area network (WAN), or the like. Itshould be appreciated that FIG. 1 depicts a simplified representation ofa data management system 100 for purposes of explanation and is notintended to limit the subject matter described herein in any way.

In exemplary embodiments described herein, the electronic devices 106,108 are realized as sensing devices. That said, in other embodiments,the computing device 102 may support communications with other medicaldevices (e.g., an infusion device, a monitoring device, and/or the like)and/or any number of non-medical client electronic devices, such as, forexample, a mobile phone, a smartphone, a tablet computer, a smart watch,or other similar mobile electronic device, or any sort of electronicdevice capable of communicating with the computing device 102 via thenetwork 110, such as a laptop or notebook computer, a desktop computer,a computer cluster, or the like. In this regard, although FIG. 1 depictsthe sensing devices 106, 108 communicating directly with the computingdevice 102 over the network 110, in alternative embodiments, the sensingdevices 106, 108 may communicate indirectly with the computing device102 via one or more intervening electronic devices (e.g., a patient'sphone).

In one or more exemplary embodiments, sensing devices 106, 108 transmit,upload, or otherwise provide data or information to the computing device102 for processing at the computing device 102 and/or storage in thedatabase 104. For example, as described in greater detail below, asensing device 106, 108 may include a sensing element that is insertedinto the body of a patient or otherwise worn by the patient to obtainmeasurement data indicative of a physiological condition in the body ofthe patient, with the sensing device 106, 108 periodically uploading orotherwise transmitting the measurement data to the computing device 102.In one or more embodiments, the sensing element is an interstitialglucose sensing element inserted into the body of a patient to obtainmeasurement data indicative of a glucose level of the interstitial fluidcompartment in the body of the patient.

The computing device 102 generally represents a server or other remotedevice configured to receive data or other information from the sensingdevices 106, 108, store or otherwise manage data in the database 104,and analyze or otherwise monitor data received from the sensing devices106, 108 and/or stored in the database 104. In practice, the computingdevice 102 may reside at a location that is physically distinct and/orseparate from the electronic devices 106, 108, such as, for example, ata facility that is owned and/or operated by or otherwise affiliated witha manufacturer of the sensing devices 106, 108 or other medical devicesutilized in connection with the data management system 100. For purposesof explanation, but without limitation, the computing device 102 mayalternatively be referred to herein as a server, a remote server, orvariants thereof.

The server 102 generally includes a processing system and a data storageelement (or memory) capable of storing programming instructions forexecution by the processing system, that, when read and executed, causeprocessing system to create, generate, or otherwise facilitate theapplications or software to perform or otherwise support the processes,tasks, operations, and/or functions described herein. Depending on theembodiment, the processing system may be implemented using any suitableprocessing system and/or device, such as, for example, one or moreprocessors, central processing units (CPUs), graphics processing units(GPUs) controllers, microprocessors, microcontrollers, processing coresand/or other hardware computing resources configured to support theoperation of the processing system described herein. Similarly, the datastorage element or memory may be realized as a random access memory(RAM), read only memory (ROM), flash memory, magnetic or optical massstorage, or any other suitable non-transitory short or long term datastorage or other computer-readable media, and/or any suitablecombination thereof. In some embodiments, the server 102 may beimplemented using a cluster of actual and/or virtual servers operatingin conjunction with each other in a conventional manner (e.g., usingload balancing, cluster management, and/or the like) or otherwiseconfigured to provide a “cloud-based” virtual server system.

In exemplary embodiments, the database 104 is utilized to store orotherwise maintain patient data for a plurality of different patients.For example, the database 104 may store or otherwise maintain referenceblood glucose measurements (e.g., a fingerstick or metered blood glucosevalue) for different patients in association with the contemporaneous orcurrent measurement parameters output by the respective sensing device106, 108 associated with a respective patient at or around the time ofthe respective blood glucose measurement. Additionally, the database 104may maintain personal information associated with the differentpatients, including the respective patient's age, gender, height,weight, body mass index (BMI), demographic data, and/or other parameterscharacterizing the respective patient.

In the illustrated embodiment, the database 104 maintains measurementdata 112 associated with previous uses of different instances of aparticular make and/or model of sensing device 106, alternativelyreferred to herein as a template sensing device (or template sensor). Insome embodiments, the make and/or model of template sensing device 106corresponds to an established or legacy sensor design or legacy sensorconfiguration for which the database 104 already maintains modeling data120 for converting measurement outputs into a calibrated measurementvalue, and accordingly, for purposes of explanation but withoutlimitation, the template sensing device 106 may alternatively bereferred to herein as a legacy sensing arrangement, legacy sensingdevice, legacy sensor or a variant thereof. In this regard, the templatesensor measurement data 112 may include measurement outputs provided bythe legacy sensing device 106 (e.g., sampled electrochemical signalvalues) that are indicative of a patient's glucose level along withcontemporaneous or corresponding reference blood glucose measurements(e.g., a fingerstick or metered blood glucose value) for the patientduring the time period corresponding to the sensor measurement outputs.For example, historical template sensor measurement data 112 may includedata obtained from different patients during a prior clinical trial,where each patient's reference blood glucose measurements (andcorresponding calibration timestamps) and measurement outputs providedby their respective instance of the legacy sensing device 106 during thetrial period are maintained in association with one another (e.g., usingone or more identifiers assigned to the respective patient).

In the illustrated embodiment, the database 104 also maintainsmeasurement data 114 associated with uses of different instances of adifferent make and/or model of sensing device 108, that is, a makeand/or model that is different from that of the template sensor 106. Insome embodiments, the make and/or model of sensing device 108corresponds to a new sensor design or new sensor configuration (e.g., anew sensing arrangement) for which the database 104 did not previouslymaintain modeling data 120 for converting measurement outputs into acalibrated measurement value. For purposes of explanation but withoutlimitation, the sensing device 108 may alternatively be referred toherein as a target sensing device (or target sensor). In this regard,the target sensor measurement data 114 may include data obtained fromdifferent patients during a current, recent, or ongoing clinical trial,where each patient's reference blood glucose measurements (andcorresponding calibration timestamps) and measurement outputs providedby their respective instance of the new sensing device 108 during thetrial period are maintained in association.

As described in greater detail below in the context of FIG. 3 , in someembodiments, the database 104 also maintains measurement data 116associated with uses of different instances of the template sensor 106concurrently with or contemporaneously to respective instances of thetarget sensor 108. For example, during a clinical trial, individualpatients may wear or otherwise utilize a first instance of a templateglucose sensor 106 concurrently with a second instance of a targetglucose sensor 108, thereby providing different glucose measurement datasets for a common patient that were concurrently obtained usingdifferent types or configurations of glucose sensors. Thus, themeasurement data 116 may include data obtained from the same patientsusing respective instances of the legacy sensor 106 during the current,recent, or ongoing clinical trial for the target sensor 108 concurrentlywith obtaining the target sensor measurement data 114, where measurementoutputs provided by the respective instances of the legacy sensingdevice 106 during the trial period are maintained in association withthe respective patient and/or the respective patient's instance of thetarget sensor 108, thereby allowing for correlations to be establishedbetween the different measurement outputs concurrently provided bydifferent sensing devices 106, 108 at or around the same time for thesame patient. In this regard, the relationships between the targetsensor measurement data 114 and the template sensor measurement data 116for the current clinical trial may be utilized to derive a model fortranslating between datasets, thereby allowing historical templatesensor measurement data 112 to be translated or otherwise converted intosimulated measurement data 118 for the target sensor 108. The new sensorsimulated measurement data 118 may then be analyzed, eitherindependently or in concert with the new sensor clinical measurementdata 114, to derive a model for calculating or otherwise determining anestimated calibrated measurement value, such as an estimated calibratedsensor glucose measurement value, as a function of the electrochemicalmeasurement outputs generated by an instance of the target sensor 108.

Although not illustrated in FIG. 1 , to support one or more embodimentsdescribed herein, the database 104 may also store or otherwise maintainlogically distinct sets of training, testing, and validation data forthe different sensors 106, 108. For example, the training set of datamay be utilized to train one or more models, with the test set of databeing utilized to optimize the resulting model(s) and the validation setof data being utilized to validate the performance or accuracy of themodel(s). In this regard, in some embodiments, the depicted sets of data112, 114, 116 may be partitioned or otherwise logically divided intovarious training, testing, and/or validation subsets. In exemplaryembodiments, the training, testing, and validation data sets aremutually exclusive.

In exemplary embodiments, the server 102 utilizes the simulatedmeasurement data 118 stored in the database 104 to determine a glucoseestimation model for a particular type, configuration, make and/or modelof sensing element and/or sensing arrangement. Thereafter, the server102 may store or otherwise maintain the data 120 characterizing thesensor glucose estimation model in the database 104 and subsequentlyprovide the sensor glucose estimation model to instances of theparticular type or configuration of sensing element and/or sensingarrangement. For example, upon initialization of an instance of asensing device 106, 108, the respective sensing device 106, 108 may beconfigured to connect to the network 110 and download or otherwiseobtain the appropriate sensor glucose estimation model from the remoteserver 102 via the network 110. Thereafter, a controller or otherprocessing system of the sensing device 106, 108 may utilize the sensorglucose estimation model to determine estimated calibrated glucosemeasurement values for a patient independent of and/or without requiringa fingerstick measurement or other calibration procedure. In yet otherembodiments, the sensor glucose estimation model may be provided toanother electronic device (e.g., an infusion device or anotherelectronic device in an infusion system) that is configured to receivemeasurement outputs from a sensing device 106, 108. In such embodiments,the infusion device or other electronic device may utilize the obtainedsensor glucose estimation model to determine estimated calibratedglucose measurement values using measurement outputs provided by theparticular sensing device 106, 108 without requiring a fingerstickmeasurement or other calibration procedure.

As described in greater detail below in the context of FIG. 6 , in someembodiments, rather than relying on concurrent template sensormeasurement data 116 (which may be absent from such embodiments), theserver 102 analyzes the target sensor measurement data 114 using agenerative adversarial network (GAN) or similar machine learningtechnique to derive a generative model representative of theelectrochemical behavior of the target sensor 108. The generative modelis then utilized by the server 102 to generate or otherwise emulateprobabilistically the measurement outputs by theoretical instances ofthe target sensor 108, and thereby obtain simulated measurement data 118that represents the expected electrochemical behavior and/orcharacteristics of the target sensor 108. The server 102 may thensimilarly utilize the simulated measurement data 118 stored in thedatabase 104, either independently or in combination with the observedtarget sensor measurement data 114, to determine a glucose estimationmodel for a particular type, configuration, make and/or model of sensingelement and/or sensing arrangement.

It should be appreciated that FIG. 1 is a simplified representation of adata management system 100 for purposes of explanation and is notintended to be limiting. In this regard, in practice, various aspects ofdata storage and/or data processing described herein in the context ofthe server 102 and/or the database 104 could equivalently be implementedon or at a sensing device 106, 108. For example, the sensing device 106,108 may implement or otherwise support a file system, an object store,or the like to store or otherwise maintain measurement data or otherreference data, which in turn, may be analyzed by or at the sensingdevice 106, 108 to generate training data, modeling data, calibrationdata, and/or the like. That said, for purposes of explanation, thesubject matter may be described primarily in the context of data storageat the database 104 with data processing performed by or at the server102.

FIG. 2 depicts an exemplary embodiment of a sensing arrangement 200suitable for use in the data management system 100 of FIG. 1 (e.g., asone or more of sensing devices 106, 108). in accordance with one or moreembodiments. The illustrated sensing device 200 includes, withoutlimitation, a controller 204, a sensing element 202, an output interface208, and a data storage element (or memory) 206. The controller 204 iscoupled to the sensing element 202, the output interface 208, and thememory 206, and the controller 204 is suitably configured to support theoperations, tasks, and/or processes described herein.

The sensing element 202 generally represents the component of thesensing device 200 that is configured to generate, produce, or otherwiseoutput one or more electrical signals indicative of a condition that issensed, measured, or otherwise quantified by the sensing device 200. Inthis regard, the physiological condition of a user influences acharacteristic of the electrical signal output by the sensing element202, such that the characteristic of the output signal generated by theelectrochemical response of the sensing element 202 corresponds to or isotherwise correlative to the physiological condition that the sensingelement 202 is sensitive to. In exemplary embodiments, the sensingelement 202 is realized as an interstitial glucose sensing element thatgenerates or otherwise provides one or more output electrical signalshaving a current, voltage, or other characteristic associated therewiththat is correlative to the interstitial fluid glucose level that issensed or otherwise measured in the body of the patient by the sensingarrangement 200. For example, the output measurement parametersgenerated or otherwise provided by the electrochemical response of theglucose sensing element 202 may include an electrical current generatedby the sensing element 202 in response to a glucose concentration(alternatively referred to as an isig value), one or moreelectrochemical impedance spectroscopy (EIS) values (for one or morefrequencies) or other measurements indicative of a characteristicimpedance associated with the sensing element 202 in response to aglucose concentration, a counter electrode voltage (Vctr) (e.g., thedifference between counter electrode potential and working electrodepotential), and/or the like. That said, it should be noted that thesubject matter described herein is not limited to signals indicative ofa physiological condition and could be implemented in an equivalentmanner for sensing elements generating signals indicative ofnon-physiological conditions.

In some embodiments, the sensing element 202 is replaceable orinterchangeable within the sensing arrangement 200. For example, apatient may periodically replace an interstitial glucose sensing element(e.g., every 3 days) and reinsert the new interstitial glucose sensingelement at the same or different location on the patient's body(alternatively referred to as a site location). In this regard, in suchembodiments, measurement data obtained from the sensing arrangement 200and/or sensing element 202 may be associated with a particular instanceof the sensing element 202 and/or the particular sensor site locationutilized with that respective instance of the sensing element 202 forpurposes of analyzing performance with respect to the age or sitelocation of the sensing element 202. In the context of such embodiments,sensor age should be understood as referring to the amount or durationof time for which an instance of the sensing element 202 has been in usefrom the initial time of insertion.

Still referring to FIG. 2 , the controller 204 generally represents theprocessing system or other hardware, circuitry, logic, firmware and/orother component(s) of the sensing device 200 that is coupled to thesensing element 202 to receive the electrical signals output by thesensing element 202 and perform various additional tasks, operations,functions and/or processes described herein. For example, the controller204 may filter, analyze or otherwise process the electrical signalsreceived from the sensing element 202 to obtain a calibrated measurementof the interstitial fluid glucose level. In one or more embodiments, thesensing device 200 comprises an instance of the target sensor 108, andthe controller 204 utilizes a glucose estimation model derived using thesimulated measurement data 118 for the target sensor 108 to calculate orotherwise determine an effectively-calibrated sensor glucose measurementvalue as a function of the output measurement parameters (e.g.,electrical current output, counter electrode voltage, electrochemicalimpedance, and the like) provided by the sensing element 202 of theinstance of the target sensor 108. In this regard, function, equation,and/or other data for the model associated with the sensing element 202may be stored or otherwise maintained in the memory 206 and downloadedfrom or otherwise provided by the remote server 102, as described ingreater detail below.

Depending on the embodiment, the controller 204 may be implemented orrealized with a general purpose processor, a microprocessor, acontroller, a microcontroller, a state machine, a content addressablememory, an application specific integrated circuit, a field programmablegate array, any suitable programmable logic device, discrete gate ortransistor logic, discrete hardware components, or any combinationthereof, designed to perform the functions described herein. In thisregard, the steps of a method or algorithm described in connection withthe embodiments disclosed herein may be embodied directly in hardware,in firmware, in a software executed by the controller 204, or in anypractical combination thereof. In exemplary embodiments, the controller204 includes or otherwise accesses the data storage element or memory206. The memory 206 may be realized using any sort of RAM, ROM, flashmemory, registers, hard disks, removable disks, magnetic or optical massstorage, short or long term storage media, or any other non-transitorycomputer-readable medium capable of storing programming instructions,code, or other data for execution by the controller 204. Thecomputer-executable programming instructions, when read and executed bythe controller 204, cause the controller 204 to perform the tasks,operations, functions, and processes described in greater detail below.

In some embodiments, the controller 204 includes an analog-to-digitalconverter (ADC) or another similar sampling arrangement that samples orotherwise converts the output electrical signal(s) received from thesensing element 202 into corresponding digital measurement data value(s)correlative to the interstitial fluid glucose level sensed by thesensing element 202. In other embodiments, the sensing element 202 mayincorporate an ADC and output a digital measurement value. In one ormore embodiments, the current of the electrical signal output by thesensing element 202 is influenced by the user's interstitial fluidglucose level, and the digital measurement data value is realized as acurrent measurement value provided by an ADC based on an analogelectrical output signal from the sensing element 202.

The output interface 208 generally represents the hardware, circuitry,logic, firmware and/or other components of the sensing arrangement 200that are coupled to the controller 204 for outputting data and/orinformation from/to the sensing device 200, for example, to/from theremote server 102 or another device on the network 110. In this regard,in exemplary embodiments, the output interface 208 is realized as acommunications interface configured to support communications to/fromthe sensing device 200. In such embodiments, the communicationsinterface 208 may include or otherwise be coupled to one or moretransceivers or communication devices capable of supporting wirelesscommunications between the sensing device 200 and another electronicdevice (e.g., an infusion device or another electronic device in aninfusion system). Alternatively, the communications interface 208 may berealized as a port that is adapted to receive or otherwise be coupled toa wireless adapter that includes one or more transceivers and/or othercomponents that support the operations of the sensing device 200described herein. In other embodiments, the communications interface 208may be configured to support wired communications to/from the sensingdevice 200. In yet other embodiments, the output interface 208 mayinclude or otherwise be realized as an output user interface element,such as a display element (e.g., a light-emitting diode or the like), adisplay device (e.g., a liquid crystal display or the like), a speakeror another audio output device, a haptic feedback device, or the like,for providing notifications or other information to the user. In suchembodiments, the output user interface 208 may be integrated with thesensing arrangement 200 (e.g., within a common housing) or implementedseparately.

It should be understood that FIG. 2 is a simplified representation of asensing device 200 for purposes of explanation and is not intended tolimit the subject matter described herein in any way. In this regard,although FIG. 2 depicts the various elements residing within the sensingdevice 200, one or more elements of the sensing device 200 may bedistinct or otherwise separate from the other elements of the sensingdevice 200. For example, the sensing element 202 may be separate and/orphysically distinct from the controller 204 and/or the communicationsinterface 208. Furthermore, features and/or functionality of describedherein as implemented by the controller 204 may alternatively beimplemented at another device within an infusion system.

FIG. 3 depicts an exemplary embodiment of a sensor translation process300 for developing a model for estimating a calibrated output of asensing arrangement using simulated measurement data obtained bytranslating measurement data from a different sensing arrangement. Thevarious tasks performed in connection with the sensor translationprocess 300 may be performed by hardware, firmware, software executed byprocessing circuitry, or any combination thereof. For illustrativepurposes, the following description may refer to elements mentionedabove in connection with FIGS. 1-2 . It should be appreciated that thesensor translation process 300 may include any number of additional oralternative tasks, the tasks need not be performed in the illustratedorder and/or the tasks may be performed concurrently, and/or the sensortranslation process 300 may be incorporated into a more comprehensiveprocedure or process having additional functionality not described indetail herein. Moreover, one or more of the tasks shown and described inthe context of FIG. 3 could be omitted from a practical embodiment ofthe sensor translation process 300 as long as the intended overallfunctionality remains intact.

The illustrated sensor translation process 300 begins by receiving orotherwise obtaining measurement data for the particular type orconfiguration of sensing arrangement to be modeled (task 302). Forexample, as described above, instances of a target sensor 108 may beprovided to a number of different individuals or patients as part of aclinical trial. In this regard, the target sensor measurement data 114includes or otherwise maintains, for each individual or patient, themeasurement parameters (e.g., output electrical current, counterelectrode voltage, electrochemical impedance, and the like) that weregenerated, output, measured, or otherwise obtained by the sensingelement 202 of the respective sensor 108 being used by the patientduring the clinical trial. The target sensor measurement data 114 mayalso maintain calibration data associated with the respective patient(e.g., timestamped reference blood glucose measurements andcorresponding calibration factors) and/or other data associated with therespective patient (e.g., demographic data and/or the like).

The sensor translation process 300 also receives or otherwise obtainsconcurrent measurement data for a different type or configuration ofsensing arrangement that is paired with a respective instance of thesensing arrangement to be calibrated and maintaining associationsbetween the different sets of concurrent measurement data (tasks 304,306). For example, during the clinical trial, instances of a templatesensor 106 may be provided to the same individuals or patients that arepart of the clinical trial for use concurrently with their respectiveinstance of the target sensor 108. Similar to the target sensormeasurement data 114, the template sensor measurement data 116 alsoincludes or otherwise maintains, for each individual or patient, themeasurement parameters (e.g., output electrical current, counterelectrode voltage, electrochemical impedance, and the like) that weregenerated, output, measured, or otherwise obtained by the sensingelement 202 of the respective template sensor 106 being used by thepatient during the clinical trial. The template sensor measurement data116 and the target sensor measurement data 114 may each be stored ormaintained using one or more unique patient identifiers that allows theremote server 102 to correlate measurements for the same patient acrossthe different sensors 106, 108. Additionally, the samples that make upthe template sensor measurement data 116 and the target sensormeasurement data 114 may be timestamped to allow the sensor translationprocess 300 to temporally associate measurement samples for the samepatient across the different sensors 106, 108.

Still referring to FIG. 3 , the sensor translation process 300 continuesby calculating or otherwise determining a predictive model forgenerating simulated measurement data for use in developing acalibration algorithm for the target sensor based at least in part onthe relationships between the paired data sets (task 308). In thisregard, based on the relationship between the target (or new) sensormeasurement data and the concurrent or contemporaneous template (orlegacy) sensor measurement data for each patient, a sensor datatranslation model is derived for translating historical legacy sensormeasurements to probable measurement values that would likely be outputor generated by the target sensor 108 having a new or different designor configuration for the given glucose dynamics that resulted in therespective historical legacy sensor measurements. That is, the templatesensor measurement data 116 provides the input variable combinations bywhich the synthetic data algorithms translate template sensormeasurement values into temporally associated simulated target sensormeasurement data 118.

In some embodiments, for each different measurement parameter to beoutput by the target sensor 108 (e.g., electrical current output,counter electrode voltage, electrochemical impedance, and the like),analytical, machine learning, or artificial intelligence techniques areutilized to determine which combination of measurement parameters outputby the template sensor 106 are correlated to or predictive of therespective measurement parameter based on the relationships between thepaired sets of observed template measurement parameter values andobserved measurement parameter value for each of the patients for whichpaired concurrent measurement data 114, 116 is maintained. Additionally,the remote server 102 may utilize analytical, machine learning, orartificial intelligence techniques to identify other contextual ornon-measurement variables that may be relevant to modeling themeasurement parameter of interest, such as, for example, the patient'sage, gender, or other demographic attributes. For example,non-measurement variables may be utilized to augment training of modelsto achieve better dataset balance, exclude irrelevant data, and/orperform other pre-processing techniques. The remote server 102 may thendetermine a corresponding equation, function, or model for calculating aprobable or expected measurement parameter value to be generated by thetarget sensor 108 based on the correlative subset of legacy sensormeasurement parameters (e.g., isig, EIS, Vctr, and/or the like) that areinput variables to the model. Thus, the sensor data translation model iscapable of characterizing or mapping a particular combination oftemplate sensor measurement parameter values to a probable measurementparameter value for the target sensor 108.

In one embodiment, a shifting translation technique is utilized toderive the sensor data translation model based on population statisticsas a function of electrical current output, counter electrode voltage,electrochemical impedance, and time from sensor connection. That is, thesensor data translation model may map a particular combination ofelectrical current output, electrode voltage and/or electrochemicalimpedance measurement values obtained via a template sensor 106 to aprobable measurement value that would be produced by the target sensor108 for one or more of the electrical current output, electrode voltageand/or electrochemical impedance. Using the shifting translationtechnique, the translation model is generated by minimizing the errorbetween the template sensors 116, after the signal has been transformed,and the paired template sensors 114. Error between the transformedtemplate sensor and target sensor may be calculated as difference inmeans of signal distributions, mean of difference between each pairedsensor reading, or similar calculation. In this regard, the translationmodel minimizes the error between the distribution of the templatesensor signal (e.g., the sequential template sensor measurement values)shifted by the model equation and the distribution of the target sensorsignal (e.g., the sequential target sensor measurement values). Possiblemodel equations include but are not limited to polynomial functions,logistic functions, and sigmoidal functions, etc. In this regard, thoseskilled in the art will appreciate that various different potentialshifting techniques and possible model equations exist, and the detailsof any particular implementation are not germane to this detaileddescription.

In another embodiment, a concatenative translation technique is utilizedto derive the translation model between template sensor 106 and targetsensor 108 as a function of electrical current output, counter electrodevoltage, electrochemical impedance, time from sensor connection, bloodglucose reference measurements, and sensor calibration data from pairedtemplate sensor trial data 116 and target sensor trial data 114. Theconcatenative translation technique segments each signal from thetemplate sensor trial data 116 and the target sensor trial data 114 intosignal units (signits) to generate a paired library. To translatetemplate sensor data 112, the template sensor data 112 is similarlyprocessed into signits. For each signit in the template sensor data 112,a nearest neighbor match is identified from the library by matching tosignits generated from the template sensor trial data 116. The match isidentified by minimizing a cost function with match and concatenationpenalties, where the calibration data is used to maintain specifiedsignal-to-calibration data relationships. Once the match is found, thecorresponding paired signit from the target sensor trial data 114 to theidentified matched signit from the template sensor data 112 is used forconcatenation. This matching process is repeated for all signits acrossthe template sensor data 112 to identify a series of signits from thebest match target sensor trial data 114 to concatenate into the fulltranslated signal. The concatenation algorithm can be configurable toallow adjustments to the signit length, the degree of adjacent signitoverlap length, the range of time from sensor connection for signits inthe library, the featurization method, data transformation methods, andmatch and concatenation cost function definitions.

In yet another embodiment, a deep neural network translation techniqueis utilized to derive the sensor data translation model as a function ofelectrical current output, counter electrode voltage, electrochemicalimpedance, and time from sensor connection from paired template sensortrial data 116 and target sensor trial data 114. The input data isprocessed to adjust data input size (segment length), length of adjacentsegment overlap (e.g. 50%), a time series smoothing parameter (e.g.3-to-1, centered or trailing smoothing), window region to filter aspecific time from sensor connection for training (e.g. days 2-5), anddata transformation methods (e.g. standardization or normalization). Theprocessed paired data from the template sensor trial data 116 and thetarget sensor trial data 114 is used to train a deep feed-forward neuralnetwork with fully connected layers and regularization. The neuralnetwork is configurable based on the number of hidden layers, the widthof hidden layers, the activation function per layer, the loss function(e.g. mean squared error (MSE), root mean squared error (RMSE), meanabsolute percentage error (MAPE), or the like), least absolute shrinkageand selection operator (LASSO) and Ridge regularization parameters,learning rate, training batch size, and number of training epochs.During translation, the processed query template sensor data 112 istranslated by the trained neural network into the target sensor data118.

Still referring to FIG. 3 , after deriving the sensor data translationmodel based on the relationship between paired measurement data sets,the sensor translation process 300 retrieves or otherwise obtainshistorical measurement data for the template (or legacy) sensor andutilizes the sensor data translation model to calculate or otherwisedetermine simulated measurement data for the target (or new) sensor bytranslating measurement data from one sensor design into another sensordesign (tasks 310, 312). In this regard, the sensor data translationmodel may be applied to a set of historical measurement data that waspreviously obtained using an instance of the template sensor 106 toconvert measurement values of that historical legacy sensor measurementdata set into a different set of measurement values that represent theprobable electrochemical behavior of the target sensor 108 to the samestimulus or conditions that produced the respective set of historicalmeasurement data. For example, if the database 104 maintains historicallegacy sensor clinical trial measurement data 112 for 4000 differentpatients, the remote server 102 may retrieve the respective data set foreach individual patient, apply the sensor data translation model to therespective data set for each individual patient to generate a simulatedmeasurement data set for that patient, and store the simulatedmeasurement data set associated with the target sensor 108 in thedatabase 104, resulting in 4000 patient sets of simulated measurementdata 118 for the target sensor 108 without actually requiring those 4000different patients to have worn or utilized the target sensor 108. Inthis manner, historical measurement data 112 from previous clinicaltrials may be mapped to a new model, make, type, and/or configuration ofsensing device 108 to effectively increase the amount of availableclinical trial data for the new model, make, type, and/or configurationof sensing device 108 without requiring patients engage in such a trial.

After generating simulated measurement data for the particular type orconfiguration of sensing arrangement to be calibrated, the sensortranslation process 300 continues by calculating or otherwisedetermining a glucose estimation model for predicting the patient'sglucose level as a function of the measurement parameters output by thesensing arrangement using the simulated measurement data (task 314). Inexemplary embodiments, the remote server 102 may create an augmented setof measurement data for the target sensor 108 by combining the observedtarget sensor clinical trial measurement data 114 with the simulatedmeasurement data 118 for the target sensor 108 to increase the size ofthe data set. For example, the observed target sensor clinical trialmeasurement data 114 may be obtained for a fewer number of patients thanthe number of patient sets of simulated measurement data 118, therebyreducing the time or costs associated with the clinical trial for thetarget sensor 108, while the simulated measurement data 118 provides alarger or more robust data set for deriving the glucose estimation modelto maintain the performance of the efficacy of the glucose estimationmodel even though the number of trial patients may be reduced. Thatsaid, in some embodiments, the glucose estimation model could be derivedsolely based on the simulated measurement data 118.

In exemplary embodiments, the glucose estimation model is utilized togenerate an estimated sensor glucose value as a function of one or moremeasurement parameters (e.g., output electrical current, counterelectrode voltage, electrochemical impedance, and the like). Forexample, a training data set for the glucose estimation model may becreated by the remote server 102 identifying and obtaining the referenceblood glucose measurement values associated with the calibration datapoints for the various patient data sets of the historical templatesensor measurement data 112 that were translated into simulatedmeasurement data 118 and utilizing the timestamps and patientidentifiers associated with those reference blood glucose measurementvalues to identify simulated measurement parameter values temporallyassociated with or otherwise corresponding to that calibration datapoint, with the reference blood glucose measurement values functioningas the output variable of the training data set and the simulatedmeasurement parameter values functioning as the input variablecombinations corresponding to the respective blood glucose measurementvalues. Similarly, the remote server 102 may identify and obtain thereference blood glucose measurement values associated with thecalibration data points for the patient data sets of the observed targetsensor measurement data 114 and utilize the timestamps and patientidentifiers to identify the temporally associated measurement parametervalues corresponding to that calibration data point for use asadditional combinations of output variable value and input variablecombinations, respectively, for the training data set.

In exemplary embodiments, the remote server 102 utilizes machinelearning techniques, such as genetic programming (GP), artificial neuralnetwork (NN), regression decision tree (DT), and/or the like to derive aglucose estimation model for predicting or estimating the patient'sinterstitial glucose measurement value to which the output measurementparameters of the target sensor 108 most likely corresponds as afunction of the measurement parameters based on the relationshipsbetween the reference blood glucose measurement values and therespective combinations of measurement parameter values. In someembodiments, the estimated sensor glucose value derived using theglucose estimation model is fused or otherwise combined with one or moreother values (e.g., a current sensor glucose measurement determinedusing a calibration factor) to arrive at a final sensor glucosemeasurement value that is output or otherwise provided to other devicesor components for other uses (e.g., generating notifications, adjustinginsulin delivery, etc.). In this regard, the estimated sensor glucosevalue may augment or otherwise adjust the normal sensor glucosemeasurement value determined using a calibration factor in a manner thataccounts for variability in the accuracy or reliability of thecalibration factor with respect to time. Examples of using machinelearning to derive sensor glucose models and determining estimatedsensor glucose values are described in greater detail in U.S. PatentApplication Pub. No. 2019/0076066.

In exemplary embodiments, after determining the glucose estimation modelfor the target sensor 108, the remote server 102 may store or otherwisemaintain the data defining the glucose estimation model in the database104 (e.g., modeling data 120) in association with the target sensor 108.In some embodiments, the remote server 102 may automatically push orotherwise provide the glucose estimation model to various instances ofthe target sensor 108 on the network 110 or to other electronic devicesthat are used in connection with the target sensor 108 (e.g., fluidinfusion devices, mobile devices, and/or the like). In otherembodiments, upon deployment, a new instance of the target sensor 108may automatically download the glucose estimation model from the remoteserver 102 via the network 110. The glucose estimation model is thenutilized in connection with the deployed instances of the target sensor108 to determine estimated sensor glucose measurement values that mayinfluence insulin delivery, patient alerts or notifications, and/or thelike.

FIG. 4 depicts a graph 400 illustrating an exemplary relationshipbetween an observed measurement parameter 402 (e.g., isig, EIS, Vctr, orthe like) with respect to time obtained using an instance of a sensor tobe modeled (e.g., target sensor 108) and the same observed measurementparameter 404 with respect to time that is concurrently obtained usingan instance of a different sensor for which translation between the twosensors is desired (e.g., template sensor 106). For example, withreference to FIG. 1 , graph line 402 may depict the observed electricalcurrent (isig) output by an instance of the target sensor 108 during aclinical trial for a patient that was concurrently using an instance ofthe template sensor 106, with the graph line 404 depicting the observedelectrical current (isig) output by the instance of the template sensor106 during the clinical trial. In this regard, the graph lines 402, 404correspond to concurrent measurement data obtained for the same patientusing the different instances of sensors 106, 108 (e.g., a firstinstance of a template sensing arrangement 106 and a second instance ofa target sensing arrangement 108). In one embodiment, the target sensormeasurement data 402 for the patient may correspond to an entry in thetarget sensor clinical trial measurement data set (e.g., data 114)maintained by the database 104 while the template sensor measurementdata 404 for the patient corresponds to an entry in the template sensorclinical trial measurement data set (e.g., data 116) maintained by thedatabase 104, with an identifier associated with the patient beingutilized to associated or otherwise correlate the entries with oneanother. As described above, the relationships between the target sensorclinical trial measurement data 114 and the template sensor clinicaltrial measurement data 116 is analyzed by the remote server 102 usingmachine learning to obtain a sensor translation model for translatingmeasurement data from the legacy sensor domain to the new sensor domain.In the graph 400 depicted in FIG. 4 , graph line 406 represents thepredicted electrical current (isig) output for the instance of thetarget sensor 108 that is calculated by applying the sensor translationmodel to the template sensor measurement data 404. Thus, the predictedtarget sensor measurement data 406 represents the expectedelectrochemical response and corresponding electrical current (isig)output that would likely be generated by the instance of the targetsensor 108 in response to the same interstitial fluid glucose levelsthat resulted in the output 404 generated by the template sensor 106. Asdescribed above, the simulated measurement data set represented by line406 may be included in the training data set used to derive the sensorglucose estimation model for the target sensor 108.

FIG. 5 depicts an exemplary embodiment of a real-time translationprocess 500 for using a sensor data translation model to leverage acalibration algorithm associated with one design, type or configurationof sensor with measurements output by a different design, type orconfiguration of sensor. For example, an existing (or legacy)calibration algorithm previously developed for a template (or legacy)sensor may be utilized to determine estimated calibrated measurementvalues in real-time using the existing calibration algorithm inconnection with an instance of a target (or new) sensor, which may bealternatively referred to herein as a backwards translation process(e.g., by translating measurement output from a new sensor effectively“backwards” in time to an older sensor domain). In this regard, thebackwards translation process may be used to leverage a legacycalibration algorithm for a new sensor without retraining the legacyalgorithm or requiring development of a calibration algorithm for thenew sensor. Conversely, the real-time translation process 500 could alsobe performed in an equivalent manner to leverage a new or more recentlydeveloped calibration algorithm for a new sensor with a legacy sensor todetermine estimated calibrated measurement values in real-time using thenew calibration algorithm in connection with an instance of the legacysensor, which may alternatively be referred to herein as a forwardstranslation process (e.g., by translating measurement output from anolder legacy sensor effectively “forwards” in time to a newer sensordomain).

The various tasks performed in connection with the real-time translationprocess 500 may be performed by hardware, firmware, software executed byprocessing circuitry, or any combination thereof. For illustrativepurposes, the following description may refer to elements mentionedabove in connection with FIGS. 1-2 . It should be appreciated that thereal-time translation process 500 may include any number of additionalor alternative tasks, the tasks need not be performed in the illustratedorder and/or the tasks may be performed concurrently, and/or thereal-time translation process 500 may be incorporated into a morecomprehensive procedure or process having additional functionality notdescribed in detail herein. Moreover, one or more of the tasks shown anddescribed in the context of FIG. 5 could be omitted from a practicalembodiment of the real-time translation process 500 as long as theintended overall functionality remains intact.

The real-time translation process 500 obtains concurrent measurementdata for different sensors, maintains associations between themeasurement data, and determines a predictive translation model forgenerating simulated measurement data in one sensor domain as a functionof measurement data from the other sensor domain based at least in parton the relationships between the paired data sets (tasks 502, 504, 506,508) in a similar manner as described above in the context of thetranslation modeling process 300 of FIG. 3 (e.g., tasks 302, 304, 306,308), and such common aspects will not be described herein in thecontext of FIG. 5 . As described above, depending on the embodiment, thetranslation model may be determined for translating from the templatesensor domain to the target sensor domain or vice versa. For purposes ofexplanation, the sensor domain that the real-time translation process500 is utilized to translate measurement values into in real-time mayalternatively be referred to herein as the destination sensor domain,while the other sensor domain may alternatively be referred to as theinitiating sensor domain. In this regard, the sensor translation modeldeveloped for the real-time translation process 500 is provided toinstances of sensors associated with the initiating sensor domain forreal-time translation of measurement values into the destination sensordomain.

As described in greater detail below, the real-time translation process500 receives or otherwise obtains the existing predictive calibrationmodel associated with the destination sensor domain, receives orotherwise obtains real-time measurements in the initiating sensordomain, and applies the translation model to translate the real-timemeasurements from the initiating sensor domain into correspondingsimulated measurement values in the destination sensor domain (tasks510, 512, 514). Thereafter, the real-time translation process 500applies the existing predictive calibration model associated with thedestination sensor domain to the simulated real-time measurements toobtain a calibrated measurement output for an instance of the initiatingsensor design using the existing calibration model associated with thedestination sensor domain (task 516).

For example, for so-called backwards translation where measurementvalues from a new sensor design or configuration corresponding to targetsensor 108 are translated into a domain associated with an older orlegacy sensor design or configuration corresponding to template sensor106, the real-time translation process 500 is performed to develop amodel for translating from the target sensor domain to the legacytemplate sensor domain (e.g., tasks 502, 504, 506, 508) in a similarmanner as described above. The translation model may then be pushed orotherwise provided to instances of the target sensor 108 for use withmeasurement values in real-time. In this regard, with reference to FIGS.1-2 , the translation model is implemented on the target sensing device108, 200 (e.g., by controller 204) for real-time translation ofmeasurements captured via the sensing element 202 of a new sensor designor configuration into simulated measurements in a legacy sensor domain(e.g., tasks 512, 514), thereby translating the measurement signals,such as electrical current output, voltage, and impedance obtained viathe sensing element 202 of the new sensor into a domain that moreclosely mimics the sensor signals the legacy calibration algorithm wastrained on. The simulated measurement values in the legacy sensor domainare then input or otherwise provided to the calibration model associatedwith the template sensor 106 to obtain a predicted or estimatedcalibrated measurement value for the target sensing device 108, 200using the legacy calibration algorithm. In this regard, the targetsensing device controller 204 may receive or otherwise obtain the legacycalibration model (e.g., from the server 102) and apply the legacycalibration model to sampled measurement values from sensing element 202after translating those measurement samples into the legacy sensordomain to calculate or otherwise determine a calibrated glucosemeasurement value according to the legacy calibration algorithm that maybe output by the target sensor 108, 200 (e.g., via output interface208). Thus, a target sensor 108 with a new design or configuration couldbe deployed without a new calibration algorithm being trained ordeveloped for the target sensor 108, but rather, estimated or predictedcalibrated measurement outputs may be obtained in accordance with anexisting calibration algorithm, thereby allowing well performingalgorithms established for other sensors to be deployed in connectionwith other sensors.

In one or more embodiments, the glucose estimation model associated witha legacy or template sensor is derived or otherwise trained usingmeasurement data obtained from instances of the legacy sensor and thenstored or otherwise maintained by the remote server 102 in the database104 for subsequent deployment to other sensor devices. Similarly, theremote server 102 may derive or otherwise determine translation modelsfor translating between the new or target sensor domain and the legacysensor domain and maintain those models in the database 104 as describedabove. Accordingly, in such embodiments, the controller 204, 722 (e.g.,as discussed in further detail below with reference to FIG. 7 )associated with an instance of a target sensor 108, 200, 702 maydownload or otherwise obtain, from the remote server 102 via a network110, the glucose estimation model associated with the legacy sensor 106along with the sensor translation model for translating from the newsensor domain to the legacy sensor domain. In this regard, thecontroller 204, 722 may then merely apply the downloaded sensortranslation model to the sampled measurement outputs of the sensingelement 202 to obtain simulated measurement data in the legacy sensordomain, and then apply the downloaded glucose estimation model to thesimulated measurement data in the legacy sensor domain to obtainestimated glucose values based on the sampled measurement outputs of thesensing element 202. The estimated glucose values may then be output orotherwise provided by the controller 204, 722 via the output interface208 for presentation to a user (e.g., via a display device or othergraphical user interface) or analysis, collection, and/or other actionby another device (e.g., an infusion device, a remote server, and/or thelike).

Similarly, for so-called forwards translation where measurement valuesfrom a legacy sensor design or configuration corresponding to templatesensor 106 are translated into a domain associated with a newer sensordesign or configuration corresponding to target sensor 108, thereal-time translation process 500 is performed to develop a model fortranslating from the template sensor domain to the target sensor domain(e.g., tasks 502, 504, 506, 508) in an equivalent manner as describedabove in the context of FIG. 3 . The translation model may then bepushed or otherwise provided to instances of the template sensor 106 foruse with measurement values in real-time. In this regard, with referenceto FIGS. 1-2 , the translation model may be implemented on the templatesensing device 106, 200 (e.g., by controller 204) for real-timetranslation of measurements captured via the sensing element 202 of alegacy sensor design or configuration into simulated measurements in anew sensor domain (e.g., tasks 512, 514). The simulated measurementvalues in the new sensor domain are then input or otherwise provided tothe calibration model associated with the target sensor 108 to obtain apredicted or estimated calibrated measurement value for the templatesensing device 106, 200 using the newer calibration algorithm. In thisregard, rather than retraining or updating a legacy sensor calibrationalgorithm, a newer or better performing calibration algorithm trained ordeveloped for the target sensor 108 may be propagated back to legacytemplate sensors 106, thereby allowing well performing algorithmsestablished for newer sensors to be deployed in connection with oldersensors.

FIG. 6 depicts an exemplary embodiment of a generative modeling process600 for developing a model for estimating a calibrated output of asensing arrangement using simulated measurement data. The various tasksperformed in connection with the generative modeling process 600 may beperformed by hardware, firmware, software executed by processingcircuitry, or any combination thereof. For illustrative purposes, thefollowing description may refer to elements mentioned above inconnection with FIGS. 1-2 . It should be appreciated that the generativemodeling process 600 may include any number of additional or alternativetasks, the tasks need not be performed in the illustrated order and/orthe tasks may be performed concurrently, and/or the generative modelingprocess 600 may be incorporated into a more comprehensive procedure orprocess having additional functionality not described in detail herein.Moreover, one or more of the tasks shown and described in the context ofFIG. 6 could be omitted from a practical embodiment of the generativemodeling process 600 as long as the intended overall functionalityremains intact.

The illustrated generative modeling process 600 initializes by receivingor otherwise obtaining measurement data for the particular type orconfiguration of sensing arrangement to be modeled (task 602). Forexample, as described above, instances of a target sensor 108 may beprovided to a number of different individuals or patients as part of aclinical trial, with the measurement outputs from the respective sensors108 being uploaded or otherwise transmitted to a remote server 102(e.g., via network 110) for storage in a database 104 in associationwith the respective individual or patient along with calibration dataassociated with the respective patient (e.g., timestamped referenceblood glucose measurements and corresponding calibration factors) orother data associated with the respective patient (e.g., demographicdata and/or the like).

In one embodiment, the generative modeling process 600 continues byassociating measurement data with calibration data points (task 604). Inthis regard, measurement data 114 for the sensor 108 to be modeled isassociated with concurrent or contemporaneous reference blood glucosemeasurement and related calibration data for a respective patient. Forexample, for each patient having a corresponding data set in the newsensor trial measurement data 114, the remote server 102 may identifydifferent calibration data points associated with the patient, and thenbased on the associated timestamps (or sensor age or time afterinsertion), identify corresponding measurement outputs from thepatient's sensor 108 that were obtained at the same time as or within athreshold amount of time of the respective calibration timestamp. Inother words, the output measurements that are not temporally relevant tothe calibration data points may be filtered or otherwise excluded fromfurther analysis. Again, it should be noted that the measurement outputsfrom the patient's sensor 108 need not be synchronous with therespective calibration timestamp but may rather be within a thresholdtime of the calibration timestamp. Moreover, one or more values withinthe threshold time of the calibration timestamp may be averaged,interpolated, or otherwise combined to arrive at a representative valueto be associated with the calibration timestamp.

After associating the measurement data with calibration data points, thegenerative modeling process 600 continues by developing or otherwiseidentifying a generative model for predicting the output measurementslikely to be generated by the sensing arrangement as a function of thecalibration factor and age (task 606). In exemplary embodiments, thegenerative model is implemented using a generative adversarial networkmade up of two neural networks. A first neural network is trained toderive a model, alternatively referred to herein as the generator model,using the respective pairs of calibration factors and timestamps (orsensor age) as conditional inputs to the generator model and thecorresponding sets of sensor output measurements (e.g., electricalcurrent, counter electrode voltage, electrochemical impedance, and thelike) as the corresponding outputs to be produced by the generatormodel. In this regard, the generator model is capable of generatingtime-varying or time-dependent synthetic values for the sensor outputmeasurements. A second neural network is trained using the same trainingdata set to derive a model, alternatively referred to herein as thediscriminator model, that votes or otherwise provides indication ofwhether a combination of input variables represents an actual orplausible combination of variables. Thus, for a given combination ofsensor output measurement values (e.g., isig, Vctr and EIS values) andcalibration data values (e.g., calibration factor and sensor age or timeafter insertion), the discriminator model provides an indication ofwhether that combination of input variables is plausible, such as, forexample, a probability that the input variable combination is realistic.In exemplary embodiments, the generator and discriminator models aretrained and function in concert with one another, such that thegenerator model generates values for the sensor output measurements fora given calibration factor and sensor age that maximizes or otherwiseoptimizes the output of the discriminator model.

After deriving a generative model, the generative modeling process 600continues by retrieving or otherwise obtaining historical calibrationdata points and providing the historical calibration data points asinput variables to the generative model to calculate or otherwisedetermine synthetic measurement data for the new sensor as a function ofthe historical calibration data points (tasks 608, 610). In this regard,the generative model may be applied to a set of historical calibrationdata that was previously obtained in connection with using an instanceof the legacy sensor 106 to generate measurement outputs by the targetsensor 108 that represent the probable electrochemical behavior of thetarget sensor 108 to the same stimulus and/or aging conditions thatresulted in the input calibration factor at a particular sensor age. Forexample, if the database 104 maintains historical legacy sensor clinicaltrial measurement data 112 for 4000 different patients, the remoteserver 102 may retrieve the respective calibration data points (e.g.,reference blood glucose measurement, calibration factor, and timestamp)for each individual patient, apply the generative model to each of thecalibration data points for each individual patient to generate asynthetic measurement data set for that patient, and store the syntheticmeasurement data set associated with the target sensor 108 in thedatabase 104, resulting in 4000 patient sets of simulated measurementdata 118. In this manner, historical measurement data 112 from previousclinical trials may be utilized to effectively increase the amount ofavailable clinical trial data for the new model, make, type, and/orconfiguration of sensing device 108 without requiring patients engage insuch a trial. Synthetic data can also be created by the generative modelby applying the generative model to simulated calibration data points.

In a similar manner as described above, after generating simulatedmeasurement data for the particular type or configuration of sensingarrangement to be calibrated, the generative modeling process 600continues by calculating or otherwise determining a glucose estimationmodel for predicting the patient's glucose level as a function of themeasurement parameters output by the sensing arrangement using thesimulated measurement data (task 612). For example, the remote server102 may create an augmented set of measurement data for the targetsensor 108 by combining the subset of observed target sensor clinicaltrial measurement data 114 associated with the calibration data pointsfrom the current clinical trial with the simulated measurement data 118for the target sensor 108 associated with historical calibration datapoints to increase the size of the training data set for the glucoseestimation model. In this regard, in a similar manner as describedabove, the glucose estimation model is trained using a training data setthat includes the combinations of synthetic measurement outputs as inputvariables (e.g., generated isig, Vctr, and EIS values from the simulatedmeasurement data 118) and the corresponding reference blood glucosemeasurement values from the historical data set (e.g., from historicallegacy sensor data 112) as the output variable of the training data set.

In a similar manner as described above, the remote server 102 mayanalyze the observed new sensor trial measurement data 114 to derive thegenerative model and then store or otherwise maintain the data definingthe generative model in the database 104 (e.g., modeling data 120) inassociation with the target sensor 108. Thereafter, the remote server102 may apply the generative model to the calibration data points fromthe historical template sensor measurement data 112 from one or moreprevious trials to generate the simulated measurement data 118corresponding to the historical calibration data points. The remoteserver 102 may then analyze the simulated measurement data 118,individually or in combination with the observed new sensor trialmeasurement data 114, to derive a glucose estimation model for thetarget sensor 108 using the synthetic measurement data. As describedabove, after determining the glucose estimation model for the targetsensor 108, the remote server 102 may store or otherwise maintain thedata defining the glucose estimation model in the database 104 (e.g.,modeling data 120) in association with the target sensor 108 fordistribution to other instances of the target sensor 108 or otherelectronic devices utilized with instances of the target sensor 108(e.g., fluid infusion devices, client electronic devices, and/or thelike).

In one embodiment, a generative modeling process involves obtainingmeasurement data from one sensor design, partitioning the measurementdata into separate training, testing, and generative folds (an optionalfold can be created for use in training the calibrated measurementalgorithm), developing a generative model for sensor output based onfeatures of sensor signals pre-conditioned on calibration data pointsfrom the training folds, and evaluating performance of the generativemodel by applying the generative model to extracted calibration datafrom the testing fold to evaluate performance. Then simulated data canbe generated by applying the generative model to extracted calibrationdata from the generative folds or simulated and used to determine apredictive model for calibrated measurement output based on trainingwith the simulated sensor measurements (synthetic data) generated sensormeasurements with or without additional sensor measurements from thecurrent sensor design.

FIG. 7 depicts an exemplary embodiment of a patient monitoring system700 that includes a medical device 702 capable of using a glucoseestimation model derived from simulated measurement data. In theillustrated embodiment, the medical device 702 is communicativelycoupled to a sensing element 704 that is inserted into the body of apatient or otherwise worn by the patient to obtain measurement dataindicative of a physiological condition in the body of the patient, suchas a sensed glucose level. In the illustrated embodiment, the medicaldevice 702 is communicatively coupled to a client device 706 via acommunications network 710, with the client device 706 beingcommunicatively coupled to a remote device 714 (e.g., remote server 102)via another communications network 712 (e.g., network 110). In thisregard, the client device 706 may function as an intermediary foruploading or otherwise providing measurement data from the medicaldevice 702 to the remote device 714. It should be appreciated that FIG.7 depicts a simplified representation of a patient monitoring system 700for purposes of explanation and is not intended to limit the subjectmatter described herein in any way. For example, some embodiments maysupport direct communications between the medical device 702 and theremote device 714 via communications network 712.

In exemplary embodiments, the client device 706 is realized as a mobilephone, a smartphone, a tablet computer, or other similar mobileelectronic device; however, in other embodiments, the client device 706may be realized as any sort of electronic device capable ofcommunicating with the medical device 702 via network 710, such as alaptop or notebook computer, a desktop computer, or the like. Inexemplary embodiments, the network 710 is realized as a Bluetoothnetwork, a ZigBee network, or another suitable personal area network.That said, in other embodiments, the network 710 could be realized as awireless ad hoc network, a wireless local area network (WLAN), or localarea network (LAN). The client device 706 includes or is coupled to adisplay device, such as a monitor, screen, or another conventionalelectronic display, capable of graphically presenting data and/orinformation pertaining to the physiological condition of the patient.The client device 706 also includes or is otherwise associated with auser input device, such as a keyboard, a mouse, a touchscreen, or thelike, capable of receiving input data and/or other information from theuser of the client device 706.

In some embodiments, a user, such as the patient, the patient's doctoror another healthcare provider, or the like, manipulates the clientdevice 706 to execute a client application 708 that supportscommunicating with the medical device 702 via the network 710. In thisregard, the client application 708 supports establishing acommunications session with the medical device 702 on the network 710and receiving data and/or information from the medical device 702 viathe communications session. The medical device 702 may similarly executeor otherwise implement a corresponding application or process thatsupports establishing the communications session with the clientapplication 708. The client application 708 generally represents asoftware module or another feature that is generated or otherwiseimplemented by the client device 706 to support the processes describedherein. Accordingly, the client device 706 generally includes aprocessing system and a data storage element (or memory) capable ofstoring programming instructions for execution by the processing system,that, when read and executed, cause processing system to create,generate, or otherwise facilitate the client application 708 and performor otherwise support the processes, tasks, operations, and/or functionsdescribed herein. Depending on the embodiment, the processing system maybe implemented using any suitable processing system and/or device, suchas, for example, one or more processors, central processing units(CPUs), graphics processing units (GPUs), controllers, microprocessors,microcontrollers, processing cores and/or other hardware computingresources configured to support the operation of the processing systemdescribed herein. Similarly, the data storage element or memory may berealized as a random-access memory (RAM), read only memory (ROM), flashmemory, magnetic or optical mass storage, or any other suitablenon-transitory short or long-term data storage or othercomputer-readable media, and/or any suitable combination thereof.

In one or more embodiments, the client device 706 and the medical device702 establish an association (or pairing) with one another over thenetwork 710 to support subsequently establishing a point-to-pointcommunications session between the medical device 702 and the clientdevice 706 via the network 710. For example, in accordance with oneembodiment, the network 710 is realized as a Bluetooth network, whereinthe medical device 702 and the client device 706 are paired with oneanother (e.g., by obtaining and storing network identificationinformation for one another) by performing a discovery procedure oranother suitable pairing procedure. The pairing information obtainedduring the discovery procedure allows either of the medical device 702or the client device 706 to initiate the establishment of a securecommunications session via the network 710.

In one or more exemplary embodiments, the client application 708 is alsoconfigured to store or otherwise maintain a network address and/or otheridentification information for the remote device 714 on the secondnetwork 712. In this regard, the second network 712 may be physicallyand/or logically distinct from the network 710, such as, for example,the Internet, a cellular network, a wide area network (WAN), or thelike. The remote device 714 generally represents a server or othercomputing device configured to receive and analyze or otherwise monitormeasurement data, event log data, and potentially other informationobtained for the patient associated with the medical device 702. Inexemplary embodiments, the remote device 714 is coupled to a database716 (e.g., database 104) configured to store or otherwise maintain dataassociated with individual patients. In practice, the remote device 714may reside at a location that is physically distinct and/or separatefrom the medical device 702 and the client device 706, such as, forexample, at a facility that is owned and/or operated by or otherwiseaffiliated with a manufacturer of the medical device 702. For purposesof explanation, but without limitation, the remote device 714 mayalternatively be referred to herein as a server.

It should be noted that in some embodiments, some or all of thefunctionality and processing intelligence of the remote computing device714 can reside at the medical device 702 and/or at other components orcomputing devices that are compatible with the patient monitoring system700. In other words, the patient monitoring system 700 need not rely ona network-based or a cloud-based server arrangement as depicted in FIG.7 , although such a deployment might be the most efficient andeconomical implementation. These and other alternative arrangements arecontemplated by this disclosure. To this end, some embodiments of thesystem 700 may include additional devices and components that serve asdata sources, data processing units, and/or recommendation deliverymechanisms. For example, the system 700 may include any or all of thefollowing elements, without limitation: computer devices or systems;patient monitors; healthcare provider systems; data communicationdevices; and the like.

Still referring to FIG. 7 , the sensing element 704 generally representsthe component of the patient monitoring system 700 that is configured togenerate, produce, or otherwise output one or more electrical signalsindicative of a physiological condition that is sensed, measured, orotherwise quantified by the sensing element 704 (e.g., sensing element202). In this regard, the physiological condition of a patientinfluences a characteristic of the electrical signal output by thesensing element 704, such that the characteristic of the output signalcorresponds to or is otherwise correlative to the physiologicalcondition that the sensing element 704 is sensitive to. In exemplaryembodiments, the sensing element 704 is realized as an interstitialglucose sensing element inserted at a location on the body of thepatient that generates an output electrical signal having a current (orvoltage) associated therewith that is correlative to or otherwiseinfluenced by the interstitial fluid glucose level that is sensed orotherwise measured in the body of the patient by the sensing element704. In some embodiments, the sensing element 704 is implemented orotherwise realized as an instance of the target sensing device 108, 200(or new sensor) having an associated glucose estimation model derivedusing simulated measurement data.

The medical device 702 generally represents the component of the patientmonitoring system 700 that is communicatively coupled to the output ofthe sensing element 704 to receive or otherwise obtain the measurementdata samples from the sensing element 704 (e.g., the measured glucoseand characteristic impedance values), store or otherwise maintain themeasurement data samples, and upload or otherwise transmit themeasurement data to the server 714 via the client device 706. In one ormore embodiments, the medical device 702 is realized as an infusiondevice configured to deliver a fluid, such as insulin, to the body ofthe patient. In such embodiments, the infusion device 702 may employclosed-loop control or other delivery control schemes that vary insulindelivery in a manner that is influenced by the patient's current glucoselevel received via the sensing element 704 or other sensing device(e.g., a continuous glucose monitor (CGM) device). That said, in otherembodiments, the medical device 702 could be a standalone sensing ormonitoring device separate and independent from an infusion device(e.g., sensing device 108, 200), such as, for example, a continuousglucose monitor (CGM) (or CGM device), an interstitial glucose sensingarrangement, or similar device. It should be noted that although FIG. 7depicts the medical device 702 and the sensing element 704 as separatecomponents, in practice, the medical device 702 and the sensing element704 may be integrated or otherwise combined to provide a unitary devicethat can be worn by the patient.

In exemplary embodiments, the medical device 702 includes a controller722, a data storage element 724 (or memory), a communications interface726, and a user interface 728. The user interface 728 generallyrepresents the input user interface element(s) and/or output userinterface element(s) associated with the medical device 702. Thecontroller 722 generally represents the processing system or otherhardware, circuitry, logic, firmware and/or other component(s) of themedical device 702 that is coupled to the sensing element 704 to receivethe electrical signals output by the sensing element 704 and perform orotherwise support various additional tasks, operations, functions and/orprocesses described herein. Depending on the embodiment, the controller722 may be implemented or realized with a general purpose processor, amicroprocessor, a controller, a microcontroller, a state machine, acontent addressable memory, an application specific integrated circuit,a field programmable gate array, any suitable programmable logic device,discrete gate or transistor logic, discrete hardware components, or anycombination thereof, designed to perform the functions described herein.In some embodiments, the controller 722 includes an analog-to-digitalconverter (ADC) or another similar sampling arrangement that samples orotherwise converts an output electrical signal received from the sensingelement 704 into corresponding digital measurement data value. In otherembodiments, the sensing element 704 may incorporate an ADC and output adigital measurement value.

The communications interface 726 generally represents the hardware,circuitry, logic, firmware and/or other components of the medical device702 that are coupled to the controller 722 for outputting data and/orinformation from/to the medical device 702 to/from the client device706. For example, the communications interface 726 may include orotherwise be coupled to one or more transceiver modules capable ofsupporting wireless communications between the medical device 702 andthe client device 706. In exemplary embodiments, the communicationsinterface 726 is realized as a Bluetooth transceiver or adapterconfigured to support Bluetooth Low Energy (BLE) communications.

In exemplary embodiments, the remote device 714 receives, from theclient device 706, measurement data values associated with a particularpatient (e.g., sensor glucose measurements, acceleration measurements,and the like) that were obtained using the sensing element 704, and theremote device 714 stores or otherwise maintains the historicalmeasurement data in the database 716 in association with the patient(e.g., using one or more unique patient identifiers). Additionally, theremote device 714 may also receive, from or via the client device 706,meal data or other event log data that may be input or otherwiseprovided by the patient (e.g., via client application 708) and store orotherwise maintain historical meal data and other historical event oractivity data associated with the patient in the database 716. In thisregard, the meal data include, for example, a time or timestampassociated with a particular meal event, a meal type or otherinformation indicative of the content or nutritional characteristics ofthe meal, and an indication of the size associated with the meal. Inexemplary embodiments, the remote device 714 also receives historicalfluid delivery data corresponding to basal or bolus dosages of fluiddelivered to the patient by an infusion device. For example, the clientapplication 708 may communicate with an infusion device to obtaininsulin delivery dosage amounts and corresponding timestamps from theinfusion device, and then upload the insulin delivery data to the remotedevice 714 for storage in association with the particular patient. Theremote device 714 may also receive geolocation data and potentiallyother contextual data associated with a device 702, 706 from the clientdevice 706 and/or client application 708, and store or otherwisemaintain the historical operational context data in association with theparticular patient. In this regard, one or more of the devices 702, 706may include a global positioning system (GPS) receiver or similarmodules, components or circuitry capable of outputting or otherwiseproviding data characterizing the geographic location of the respectivedevice 702, 706 in real-time.

In various embodiments, the remote device 714 may implement, facilitate,support or otherwise perform the sensor translation process 300 of FIG.3 or the generative modeling process 600 of FIG. 6 to obtain a glucoseestimation model associated with the sensing element 704. Thereafter,the remote device 714 may push or otherwise provide the glucoseestimation model to the medical device 702 and/or the client device 706for determining an estimated sensor glucose value in real-time based onmeasurement data samples obtained via sensing arrangement 704. Forexample, when the medical device 702 is realized as an infusion device,the glucose estimation model may be utilized to adjust or otherwiseaugment the current sensor glucose measurement value determined using acalibration factor with a current estimated sensor glucose value toarrive at an adjusted sensor glucose measurement value that accounts foraging of the sensing element 704 since the most recent calibration.Based on a difference between the adjusted sensor glucose measurementvalue and a target glucose value for a patient, the infusion device 702may determine a corresponding amount of insulin to be delivered toreduce the different and autonomously operate a motor or other actuationarrangement of the infusion device 702 in accordance with the deliverycommand to displace a plunger or otherwise dispense insulin from areservoir of the infusion device 702. That said, in other embodiments,the medical device 702 and/or the client application 708 may utilize thecurrent estimated sensor glucose value and/or the adjusted sensorglucose measurement value to provide alerts or other notifications to auser (e.g., hyperglycemia and/or hypoglycemia alerts, alerts to replaceor change the sensing element 704, alerts to change the insertion sitefor the sensing element 704, etc.). In this regard, the subject matterdescribed herein is not limited to any particular application or use ofthe glucose estimation model or estimated sensor glucose valuesdetermined therefrom. Additionally, as described, in variousembodiments, the remote device 714 may facilitate or otherwise supportdevelopment of different sensor translation models, generative models,and the like in connection with one or more of the processes 300, 500,600 described above using measurement data maintained in the database716, maintain the modeling data (e.g., in the database 716), and push orotherwise provide modeling data to different instances of the medicaldevice 702 (e.g., sensors 106, 108) as appropriate for real-timedeployment or application at a medical device 702.

In one or more embodiments, the remote device 714 may facilitate orotherwise support the real-time translation process 500 of FIG. 5 bydeveloping and providing a translation model to the medical device 702and/or the client device 706 for translating measurement data samplesobtained via the sensing arrangement 704 to a legacy sensor domain inreal-time. For example, the medical device 702 may utilizes thetranslation model to translate measurements captured via the sensingelement 202, 704 of a new sensor design or configuration into simulatedmeasurements in a legacy sensor domain, and then apply a legacy glucoseestimation model to the simulated measurements to obtain an estimatedcalibrated measurement value that may be utilized by the medical device702 (e.g., to determine insulin delivery commands, generate graphicaluser interface displays, and/or the like) or provided to another device706. Thus, a sensing element 704 with a new design or configurationcould be deployed in the system 700 without a new calibration algorithm(or glucose estimation model) being trained or developed for the sensingelement 704, but rather, estimated or predicted calibrated measurementoutputs may be obtained in accordance with an existing calibrationalgorithm, thereby allowing well performing algorithms established forother sensors to be deployed in connection with sensing element 704.

For the sake of brevity, conventional techniques related to glucosesensing and/or monitoring, sampling, filtering, calibration, closed-loopglucose control, machine learning, artificial intelligence, and otherfunctional aspects of the subject matter may not be described in detailherein. In addition, certain terminology may also be used in the hereinfor the purpose of reference only, and thus is not intended to belimiting. For example, terms such as “first”, “second”, and other suchnumerical terms referring to structures do not imply a sequence or orderunless clearly indicated by the context. The foregoing description mayalso refer to elements or nodes or features being “connected” or“coupled” together. As used herein, unless expressly stated otherwise,“coupled” means that one element/node/feature is directly or indirectlyjoined to (or directly or indirectly communicates with) anotherelement/node/feature, and not necessarily mechanically.

While at least one exemplary embodiment has been presented in theforegoing detailed description, it should be appreciated that a vastnumber of variations exist. It should also be appreciated that theexemplary embodiment or embodiments described herein are not intended tolimit the scope, applicability, or configuration of the claimed subjectmatter in any way. For example, the subject matter described herein isnot necessarily limited to the infusion devices and related systemsdescribed herein. Moreover, the foregoing detailed description willprovide those skilled in the art with a convenient road map forimplementing the described embodiment or embodiments. It should beunderstood that various changes can be made in the function andarrangement of elements without departing from the scope defined by theclaims, which includes known equivalents and foreseeable equivalents atthe time of filing this patent application. Accordingly, details of theexemplary embodiments or other limitations described above should not beread into the claims absent a clear intention to the contrary.

What is claimed is:
 1. A computer system, comprising: one or moreprocessors; and memory storing instructions which, when executed by theone or more processors, cause the computer system to perform operationscomprising: generating simulated measurements for a first sensor basedon historical measurements associated with a second sensor, wherein: thesecond sensor has a different design or configuration than the firstsensor, the historical measurements represent changes in a physiologicalcondition as observed by different instances of the second sensor, andgenerating the simulated measurements comprises applying a translationmodel to convert the historical measurements into measurements thatwould have been produced by the first sensor; determining an estimationmodel using the simulated measurements, wherein the estimation model isconfigured to estimate a value of the physiological condition given anactual measurement from the first sensor; and providing one or moreelectronic devices with access to the estimation model, the one or moreelectronic devices comprising at least one device configured to applythe estimation model to a measurement from a corresponding instance ofthe first sensor.
 2. The computer system of claim 1, wherein theoperations further comprise: determining the translation model based atleast in part on relationships between first measurements associatedwith the first sensor and second measurements associated with the secondsensor, wherein the second measurements are separate from the historicalmeasurements.
 3. The computer system of claim 2, wherein each of thefirst measurements was captured contemporaneously with a correspondingone of the second measurements.
 4. The computer system of claim 1,wherein the historical measurements correspond to values of electricalsignals generated by the different instances of the second sensor inresponse to the physiological condition.
 5. The computer system of claim1, wherein the estimation model is applied to convert the measurementfrom the corresponding instance of the first sensor into an estimatedvalue of the physiological condition.
 6. The computer system of claim 1,wherein determining the estimation model comprises analyzing thesimulated measurements together with reference values for thephysiological condition.
 7. The computer system of claim 6, wherein thereference values comprise a corresponding reference measurement for eachof the historical measurements.
 8. The computer system of claim 6,wherein the first sensor and the second sensor are interstitial glucosesensors, and wherein the reference values comprise blood glucosemeasurements.
 9. The computer system of claim 6, wherein analyzing thesimulated measurements together with reference values for thephysiological condition comprises determining relationships between thesimulated measurements and the reference values.
 10. The computer systemof claim 6, wherein determining the estimation model further comprisesanalyzing actual measurements from different instances of the firstsensor together with corresponding reference values.
 11. The computersystem of claim 10, wherein the actual measurements from differentinstances of the first sensor comprise measurements that were used todetermine the translation model.
 12. The computer system of claim 1,wherein providing one or more electronic devices with access to theestimation model comprises sending the estimation model to the one ormore electronic devices over a communications network.
 13. A method ofproviding an estimation model for use with one or more instances of afirst sensor, the method comprising: generating, by a computer system,simulated measurements for the first sensor based on historicalmeasurements associated with a second sensor, wherein: the second sensorhas a different design or configuration than the first sensor, thehistorical measurements represent changes in a physiological conditionas observed by different instances of the second sensor, and generatingthe simulated measurements comprises applying a translation model toconvert the historical measurements into measurements that would havebeen produced by the first sensor; determining the estimation modelusing the simulated measurements, wherein the estimation model isconfigured to estimate a value of the physiological condition given anactual measurement from the first sensor; and providing, by the computersystem, one or more electronic devices with access to the estimationmodel, the one or more electronic devices comprising at least one deviceconfigured to apply the estimation model to a measurement from acorresponding instance of the first sensor.
 14. The method of claim 13,further comprising: determining the translation model based at least inpart on relationships between first measurements associated with thefirst sensor and second measurements associated with the second sensor,wherein the second measurements are separate from the historicalmeasurements.
 15. The method of claim 14, wherein each of the firstmeasurements was captured contemporaneously with a corresponding one ofthe second measurements.
 16. The method of claim 13, wherein thehistorical measurements correspond to values of electrical signalsgenerated by the different instances of the second sensor in response tothe physiological condition.
 17. The method of claim 13, wherein theestimation model is applied to convert the measurement from thecorresponding instance of the first sensor into an estimated value ofthe physiological condition.
 18. The method of claim 13, whereindetermining the estimation model comprises analyzing the simulatedmeasurements together with reference values for the physiologicalcondition, and wherein the reference values comprise a correspondingreference measurement for each of the historical measurements.
 19. Themethod of claim 18, wherein the first sensor and the second sensor areinterstitial glucose sensors, and wherein the reference measurements areblood glucose measurements.
 20. The method of claim 13, whereinproviding one or more electronic devices with access to the estimationmodel comprises sending the estimation model to the one or moreelectronic devices over a communications network.